The addrs.UniqueKey and addrs.UniqueKeyer mechanism was a compromise we introduced as part of the config-driven move project as a way to make maps with addresses as keys even though a lot of our address types aren't comparable.

We had previously done this typically by using string representations of the address types (.String()) directly as map keys, which works okay most of the time but runs into trouble in situations where the string representations are ambiguous, such as that an addrs.ResourceInstance with no key and an addrs.Resource can have an identical string representation. The addrs.UniqueKey idea allowed us to dynamically retain distinctions between the address types internally even if we are still ultimately doing just string comparisons for some of them, because all of the address types have distinct implementations of addrs.UniqueKey and thus are treated as distinct keys in a Go map.

However, that compromise still didn't address the fact that the map key types could not be statically checked by the compiler, making it easy to erroneously put a key of the wrong type into a map and have that cause erratic behavior at runtime rather than a compile-time error.

This PR therefore completes what I previously attempted with addrs.Set (which I had actually not intended to include in the addrs.UniqueKey PR before; whoops!), now making use of Go 1.18 type parameter syntax to define generic addrs.Set and addrs.Map types that can take specific addrs.UniqueKeyer implementations as their key types, with write operations checked at compile time.

The main event here is actually addrs.Map, which can store a value of a chosen type alongside each element. Unfortunately in the process we lose the ability to use standard Go indexing syntax to work with the map, and so we need to use a method-based API instead. I converted the refactoring package to use addrs.Map to see if it still felt reasonably ergonomic, and I subjectively think it's still readable enough and therefore a net win when considering the benefit of type safety, but of course that's my own bias towards compile-time checks that others might not share. (The original motivation for the addrs package was to allow compile-time checking of address types, where beforehand we were just passing specially-formatted string values everywhere and routinely getting their "types" confused, so this at least seems consistent with that mission.)

I decided to leave the internals of these structures exported rather than hidden as a matter of pragmatism, because it brings the following benefits:

• We can use our typical approaches like cmp.Equal and cmp.Diff with these data structures in tests without the need for any special extra cmp options.

• For addrs.Set, it's reasonable to range directly over the values of the set to efficiently visit them all without any copying. It could perhaps be reasonable to do this with the Elems field of addrs.Map too, but that would expose the caller to the MapElement type, so I guess we'll see from experience whether that's actually useful and a good idea.

  (Note: The addrs.Map is intentionally a struct with a map field inside it rather than just a named type directly for a map type because with the latter I found the compiler gave confusing feedback if I accidentally used the normal Go indexing syntax with an addrs.Map value, because it looked like a type error on the key rather than reporting that it's a type that doesn't support indexing at all.)

As noted in the documentation comments, callers should not directly modify the internals even though the compiler would allow it. The internals are exposed for reading only.

I worked on this now really because I'm about to start working on something else that will, I hope, use of both addrs.Set and addrs.Map as part of its implementation. I wanted to get feedback on this in isolation first though, using the refactoring package changes to explore the ergonomics of it, so that if we decide to change the design here or to not move forward with it at all then I can avoid the need to retroactively replace uses of these new types in my ongoing project work.

The changes to the refactoring package here should be just a mechanical replacement of one usage pattern with another, with no change in behavior. If anything looks like it's doing something materially different than the code it replaced then that's a mistake on my part, so please point it out!